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DETAILED ACTION 

1 . A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1 .17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.114. Applicant's submission filed on March 21, 2005 has been entered. Claims 1-23 
are now pending. 

Response to Arguments 

2. Applicant's arguments have been fully considered but they are not persuasive. 

3. In response to Applicant's arguments that there is no suggestion to combine the 
references (Applicant's remarks, pages 12, 15 and 16), the examiner recognizes that obviousness 
can only be established by combining or modifying the teachings of the prior art to produce the 
claimed invention where there is some teaching, suggestion, or motivation to do so found either 
in the references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988) and/« re Jones, 958 
F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). 

In each case, Applicant contends that the examiner has not provided in the Office action a 
suggestion or motivation to combine the references but has merely made a conclusion about what 
may be provided through the combination of these references. However, it should be noted that 
for each combination, a suggestion or motivation to combine the references found in the 
references themselves is cited in the Office action. One of ordinary skill in the art would have 
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been motivated to supplement one reference with features from another for the reasons or 
advantages cited in the Office action. 

4. Applicant contends that Peercy and Pavan, alone or in combination, do not teach that "the 
application graph can be traversed by a graphical application platform at run time to execute 
appropriate processing blocks on a run time platform," because Peercy and Pavan are directed 
toward compile-time related technologies rather than run-time related technologies (Applicant's 
remarks, page 13, second paragraph). 

However, the translation disclosed by Pavan is indeed performed at runtime, when the 
application is submitted for execution (see, for example, column 12, lines 1-13). The application 
graph is traversed at runtime during this translation to execute appropriate processing blocks on a 
runtime platform (see, for example, column 8, line 51 to column 9, line 9). 

5. Applicant further contends that Peercy and Pavan, alone or in combination, do not teach 
"an application graph that expresses the identity of the stored processing blocks and data 
connectivity between the stored processing blocks" (Applicant's remarks, page 13, third 
paragraph). 

However, Pavan expressly discloses an application graph (see, for example, user program 
400 in FIG. 4) that expresses the identity of the stored processing blocks (see, for example, 
column 4, lines 28-37) and data connectivity between the stored processing blocks (see, for 
example, column 5, lines 8-14, and column 6, lines 18-26). 
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6. Applicant further contends that Peercy and Pavan, alone or in combination, do not teach, 
for example, "wherein the application real time kernel modifies the connections between said 
blocks at run time" (Applicant's remarks, page 14, second paragraph). 

However, Pavan discloses that blocks are inserted into the application graph (see, for 
example, column 8, lines 60-67) and that the connections between the blocks are modified at 
runtime (see, for example, column 11, lines 2-12 and 20-32) when the application is submitted 
for execution (see, for example, column 12, lines 1-13). 

7. Applicant contends that neither Peercy nor Barbour, alone or in combination, discloses 
"(b) mapping at least one block, corresponding to the selected implementation, to a phase of 
execution." Specifically, Applicant contends that Peercy does not disclose this element because 
Peercy discloses a compile-time translation (Applicant's remarks, page 17, first paragraph). 

However, "mapping at least one block . . . to a phase of execution" does not imply 
executing the block. The plain language of the claim does not exclude Peercy and Barbour. 
Peercy discloses mapping an abstract expression, which is to say a block, to an intermediate tree 
representation (see, for example, steps 206 and 208 in FIG. 2, and column 5, lines 35-45). The 
intermediate tree representation comprises phases of execution (see, for example, FIG. 3). 
Therefore, Peercy discloses mapping at least one block to a phase of execution. Although the 
claims are interpreted in light of the specification, limitations from the specification are not read 
into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

Claim Rejections - 35 USC §112 

8. The following is a quotation of the second paragraph of 35 U.S. C. 112: 
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The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

9. Claims 20-23 are rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which Applicant regards as 
the invention. 

Claim 20 is considered indefinite because it does not clearly set forth the metes and 
bounds of the patent protection desired. The preamble recites a method of "dynamically 
configuring the execution of an application." However, the recited method steps are directed to 
loading, executing and dynamically modifying "an application graph." The relationship between 
the application and the application graph is not clearly defined in the claim. Therefore, it is not 
clear how dynamically modifying the application graph, as recited, serves to dynamically 
configure the execution of the application, as intended. The ambiguity could be remedied, for 
example, by reciting —loading an application graph of the application— in line 3, and/or by 
further defining the application graph in terms of the application. 

Claims 21-23 are considered indefinite because they depend upon claim 20. 

Claim Rejections - 35 USC § 103 

10. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 
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11. Claims 1-8, 10, 1 1 and 16-19 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over U.S. Pat. No. 6,578,197 to Peercy et al. (art of record, "Peercy") in view of U.S. Pat. No. 
6,502,238 to Pavan et al. (art of record, "Pavan"). 

With respect to claim 1 (original), Peercy discloses a method for supporting development 
of content independent of a run- time platform (see, for example, the abstract and FIG. 1). 

Although Peercy discloses using procedures and functions to define graphics content 
(see, for example, column 6, lines 10-20), Peercy does not expressly disclose the step of: 

(a) storing processing blocks that define content. 

However, Pavan discloses storing processing blocks, accessible to the user, that define 
the content of a program (see, for example, column 4, lines 28-37). The processing blocks 
encapsulate functions performed by hardware and functions that are otherwise hidden from the 
user (see, for example, column 4, lines 9-18). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the method of Peercy with processing blocks, such as taught by Pavan, 
so as to encapsulate and provide access to functions performed by hardware and functions that 
are otherwise hidden from the user. 

Although Peercy discloses storing a tree or application graph that represents a graphics 
computation (see, for example, step 208 in FIG. 2, FIG. 3 and column 4, lines 14-16), and further 
discloses traversing the tree in a graphical application platform (see, for example, step 210 in 
FIG. 2) to execute the graphics computation (see, for example, steps 212 and 214 in FIG. 2), 
Peercy does not expressly disclose the step of: 
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(b) storing an application graph that expresses the identity of the stored processing blocks 
and data connectivity between the stored processing blocks, whereby the application graph can 
be traversed by a graphical application platform at run time to execute appropriate processing 
blocks on a run time platform. 

However, Pavan further discloses storing an application graph (see, for example, user 
program 400 in FIG. 4) that represents the identity of the stored processing blocks and the data 
connectivity between the blocks (see, for example, column 5, lines 8-14, and column 6, lines 18- 
26). Pavan further discloses that the application graph is traversed and translated at runtime to 
execute appropriate processing blocks on a runtime platform (see, for example, column 8, line 51 
to column 9, line 9). The traversal is performed at runtime when the application is submitted for 
execution (see, for example, column 12, lines 1-13). Program fragments are automatically and 
transparently created and distributed for execution over a network based on the application graph 
(see, for example, column 1 1, lines 50-63). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the method of Peercy with an application graph, such as taught by 
Pavan, so as to automatically and transparently create and execute a distributed program for the 
graphics computation of Peercy. 

With respect to claim 2 (original), Peercy further discloses the limitation wherein the 
content comprises game content (see, for example, column 1, lines 16-23, which shows 
developing graphics applications for the entertainment industry, and column 1 1, lines 1-2, which 
further shows using video game cartridges). 
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With respect to claim 3 (original), Peercy discloses a method for supporting development 
of content independent of multiple hardware platforms (see, for example, the abstract and FIG. 1). 

Although Peercy discloses using procedures and functions to define graphics content 
independent of multiple hardware platforms (see, for example, column 6, lines 10-20), Peercy 
does not expressly disclose the step of: 

(a) storing processing blocks that define content independent of multiple hardware 
platforms. 

However, Pavan discloses storing processing blocks, accessible to the user, that define 
the content of a program (see, for example, column 4, lines 28-37) independent of multiple 
hardware platforms (see, for example, column 5, lines 25-32). The processing blocks 
encapsulate functions performed by hardware and functions that are otherwise hidden from the . 
user (see, for example, column 4, lines 9-18). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the method of Peercy with processing blocks, such as taught by Pavan, 
so as to encapsulate and provide access to functions performed by hardware and functions that 
are otherwise hidden from the user. 

Peercy further discloses the step of: 

(b) selecting a target hardware platform from multiple hardware platforms (see, for 
example, step 140 in FIG. 1 and column 6, lines 37-39, which shows targeting or selecting a 
hardware platform). 

Although Peercy discloses storing a tree or application graph that represents a graphics 
computation (see, for example, step 208 in FIG. 2, FIG. 3 and column 4, lines 14-16), and further 
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discloses traversing the tree (see, for example, step 210 in FIG. 2) to execute the graphics 
computation on the selected target hardware platform (see, for example, steps 212 and 214 in 
FIG. 2), Peercy does not expressly disclose the steps of: 

(c) storing an application graph that expresses the identity of the stored processing blocks 
and data connectivity between the stored processing blocks based on the selected target hardware 
platform; and 

(d) traversing the application graph at run time, including executing appropriate 
processing blocks on the selected target hardware platform. 

However, Pavan further discloses storing an application graph (see, for example, user 
program 400 in FIG. 4) that represents the identity of the stored processing blocks and the data 
connectivity between the blocks (see, for example, column 5, lines 8-14, and column 6, lines 18- 
26). Pavan further discloses that the application graph is traversed and translated at runtime to 
execute appropriate processing blocks on a selected target hardware platform (see, for example, 
column 8, line 5 1 to column 9, line 9). The traversal is performed at runtime when the 
application is submitted for execution (see, for example, column 12, lines 1-13). Program 
fragments are automatically and transparently created and distributed for execution over a 
network based on the application graph (see, for example, column 11, lines 50-63). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the method of Peercy with an application graph, such as taught by 
Pavan, so as to automatically and transparently create and execute a distributed program for the 
graphics computation of Peercy. 
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With respect to claim 4 (original), Peercy further discloses the limitation wherein the 
content comprises game content (see, for example, column 1, lines 16-23, which shows 
developing graphics applications for the entertainment industry, and column 11, lines 1-2, which 
further shows using video game cartridges), and the multiple hardware platforms include at least 
one of a game console platform and a personal computer platform (see, for example, FIG. 5, 
which shows a computer platform, and column 11, lines 1-2, which shows a game device or 
console platform). 

With respect to claim 5 (currently amended), Peercy discloses a game development and 
run time system (see, for example, the abstract and FIG. 1), comprising a graphical application 
platform that enables a game application to run on any of multiple hardware platforms (see, for 
example, column 6, lines 2-20, which shows a graphical application platform that enables an 
application to run on any of multiple hardware platforms, and column 1, lines 16-23, which 
further shows developing graphics applications for the entertainment industry). 

Although Peercy discloses using an abstract representation to implement standard 
graphics features and capabilities of a hardware platform (see, for example, column 5, lines 35- 
45), Peercy does not expressly disclose: 

(a) an application real time kernel, 

(b) a plurality of standard features implemented as executable blocks of logic, and 

(c) connections between said blocks that implement data flow between said blocks such 
that capabilities of the game application and any of the multiple hardware platforms can be 
implemented modularly by adding additional corresponding blocks and connections, 
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wherein the application real time kernel modifies the connections between said blocks at 
run time. 

However, Pavan discloses a kernel for the simultaneous, real-time control of applications 
having multiple inputs and outputs (see, for example, column 2, lines 3-14). Pavan further 
discloses a plurality of standard features implemented as blocks (see, for example, column 4, 
lines 9-18), and connections between the blocks that implement data flow (see, for example, 
column 5, lines 8-14). Blocks and connections are added modularly to implement the 
capabilities of the application (see, for example, column 4, lines 28-37) and the hardware 
platform (see, for example, column 6, lines 45-63). Pavan further discloses that the blocks and 
connections are modular (see, for example, column 4, lines 19-26), and encapsulate functions 
performed by hardware and functions that are otherwise hidden from the user (see, for example, 
column 4, lines 9-18). 

Pavan further discloses that blocks are inserted (see, for example, column 8, lines 60-67) 
and that the connections are modified at runtime (see, for example, column 1 1, lines 2-12 and 
20-32) when the application is submitted for execution (see, for example, column 12, lines 1-13), 
so as to automatically and transparently create and distribute program fragments for execution 
over a network (see, for example, column 1 1, lines 50-63). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the system of Peercy with an application real time kernel, blocks and 
connections, such as taught by Pavan, so as to encapsulate and provide access to functions 
performed by hardware and functions that are otherwise hidden from the user, and to 
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automatically and transparently create and execute a distributed program for the graphics 
features of Peercy that can run in real-time. 

With respect to claim 6 (original), although Peercy discloses that the application can run 
on a target hardware platform (see, for example, column 6, lines 2-9), and further discloses a tree 
or application graph (see, for example, step 208 in FIG. 2, FIG. 3 and column 4, lines 14-16), 
Peercy does not expressly disclose an object definition tool that enables a developer to define an 
application graph. 

However, Pavan discloses an object definition tool that enables a user to define an 
application graph (see, for example, column 6, lines 18-26), so as to simplify the programming 
for the user (see, for example, column 7, lines 37-49). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made supplement the system of Peercy with an object definition tool, such as taught by 
Pavan, so as to simplify the programming for the user. 

With respect to claim 7 (original), Peercy in view of Pavan further discloses the 
limitation wherein said object definition tool further enables a developer to define objects, object 
elements, and connections (see, for example, Pavan, column 5, line 25 to column 6, lines 8, 
which shows that the user defines objects, elements of the objects, and connections between the 
objects). 

With respect to claim 8 (currently amended), the limitations recited in the claim are 
analogous to those of claim 5 (see the rejection of claim 5 above). 
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With respect to claim 10 (original), Peercy in view of Pavan further discloses the 
limitation wherein said additional blocks implement additional features, said additional features 
comprising market oriented features (see, for example, Pavan, column 4, lines 9-18, which shows 
that the blocks implement functions or features, and column 1, line 56 to column 2, line 2, which 
further shows market-oriented features). 

With respect to claim 1 1 (original), Peercy in view of Pavan further discloses the 
limitation wherein said additional blocks implement additional features, said additional features 
comprising application specific features (see, for example, Pavan, column 4, line 48 to column 5, 
line 7, which shows that the blocks implement application-specific features). 

With respect to claim 16 (previously presented), the limitations recited in the claim are 
analogous to those of claim 1 (see the rejection of claim 1 above). 

With respect to claim 17 (previously presented), the limitations recited in the claim are 
analogous to those of claim 2 (see the rejection of claim 2 above). 

With respect to claim 18 (previously presented), the limitations recited in the claim are 
analogous to those of claim 3 (see the rejection of claim 3 above). 

With respect to claim 19 (previously presented), the limitations recited in the claim are 
analogous to those of claim 4 (see the rejection of claim 4 above).. 
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12. Claim 9 is rejected under 35 U.S.C. 103(a) as being unpatentable over Peercy in view of 
Pavan, as applied to claim 8 above, and further in view of U.S. Pat. No. 6,584,489 to Jones et al. 
(art of record, "Jones"). 

With respect to claim 9 (original), although Peercy in view of Pavan discloses resource 
scheduling and other kernel services (see, for example, Pavan, column 6, lines 45-63), Peercy in 
view of Pavan does not expressly disclose the limitation wherein said ARK comprises logic that 
invokes blocks according to a schedule listing the blocks to be executed in each of at least one 
ARK thread running on at least one central processing unit, dynamically loads and unloads 
blocks, monitors block execution, and facilitates thread management, memory sharing, mutual 
exclusion, and synchronization. 

However, Jones discloses invoking blocks according to a schedule for one or more 
threads on one or more processors (see, for example, column 6, lines 9-26). Jones further 
discloses monitoring execution to dynamically load and unload resources or blocks (see, for 
example, column 14, lines 41-48). Jones further discloses managing threads (see, for example, 
column 18, lines 18-39) and resources such as shared memory (see, for example, column 5, lines 
16-28). Jones further discloses mutual exclusion and synchronization (see, for example, column 
25, lines 41-47). The scheduling and management features of Jones provide dynamic and 
adaptable support for resources in distributed, real-time applications (see, for example, column 4, 
lines 57-67). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the system of Peercy and Pavan with scheduling and management 
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features, such as taught by Jones, so as to provide dynamic and adaptable support for resources 
in the distributed, real-time graphics application of Peercy and Pavan. 

13. Claim 12 is rejected under 35 U.S.C. 103(a) as being unpatentable over Peercy in view of 
Pavan, as applied to claim 8 above, and further in view of U.S. Pat. No. 5,857,106 to Barbour et 
al. (art of record, herein "Barbour"). 

With respect to claim 12 (original), although Peercy in view of Pavan further discloses 
the limitation wherein said standard and additional blocks are organized into components (see, 
for example, Pavan, column 4, lines 19-26, which shows primitive or standard blocks and 
composite or additional blocks, and column 4, lines 2-5, which shows organizing the blocks into 
objects or components), Peercy in view of Pavan does not expressly disclose the limitation 
wherein each component comprises blocks representing alternative implementations of a feature. 

However, Barbour discloses libraries or components comprised of modules or blocks that 
represent alternative implementations of features for different hardware architectures, so as to 
provide optimized performance for a selected hardware platform (see, for example, column 1, 
lines 55-65, and column 2, lines 53-61). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the system of Peercy and Pavan with alternative implementations, such 
as taught by Barbour, so as to optimize performance for a selected hardware platform. 

14. Claim 13 is rejected under 35 U.S.C. 103(a) as being unpatentable over Peercy in view of 
Pavan in view of Barbour, as applied to claim 12 above, and further in view of Jones. 



Application/Control Number: 09/779,453 Page 16 

Art Unit: 2192 

With respect to claim 13 (original), Peercy in view of Pavan in view of Barbour further 
discloses the limitation wherein each of said alternative implementations comprises: 

(a) blocks corresponding to said alternative implementation (see, for example, Barbour, 
column 1, lines 55-65, and column 2, lines 53-61). 

Although Peercy in view of Pavan in view of Barbour discloses identifying the processor 
and architecture (see, for example, Barbour, column 3, lines 29-39), Peercy in view of Pavan in 
view of Barbour does not expressly disclose: 

(b) identification of resources needed by said alternative implementation; and 

(c) identification of resources provided by said alternative implementation. 

However, Jones discloses identifying resources that are needed (see, for example, column 
9, lines 38-61) and resources that are provided (see, for example, column 9, lines 8-14), so as to 
provide dynamic and adaptable resource management for distributed, real-time applications (see, 
for example, column 4, lines 57-67). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the system of Peercy, Pavan and Barbour with resource identification, 
such as taught by Jones, so as to provide dynamic and adaptable resource management for the 
distributed, real-time graphics application of Peercy, Pavan and Barbour. 

15. Claims 14 and 15 are rejected under 35 U.S. C. 103(a) as being unpatentable over Peercy 
in view of Barbour. 
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With respect to claim 14 (original), Peercy discloses a method of pre processing a 
graphics application with respect to a predefined hardware platform (see, for example, the 
abstract and FIG. 1). 

Although Peercy discloses targeting a hardware platform (see, for example, column 6, 
lines 2-9), Peercy does not expressly disclose: 

(a) selecting from among a set of alternative implementations of a feature. 
However, Barbour discloses selecting an implementation of a feature (see, for example, 

column 3, lines 29-39) from among a set of modules or blocks that correspond to alternative 
implementations (see, for example, column 2, lines 29-39), so as to provide optimized 
performance for a selected hardware platform (see, for example, column 1, lines 55-65, and 
column 2, lines 53-61). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the method of Peercy with alternative implementations, such as taught 
by Barbour, so as to optimize performance for the targeted hardware platform. 

Peercy further discloses: 

(b) mapping at least one block, corresponding to the selected implementation, to a phase 
of execution (see, for example, steps 206 and 208 in FIG. 2 and column 5, lines 35-45, which 
shows mapping an abstract expression or block to an intermediate tree representation, and FIG. 
3, which shows that the tree comprises phases of execution); 

(c) mapping a phase of execution to a stage of execution (see, for example, step 210 in 
FIG. 2 and column 5, lines 46-50, which shows processing the tree to map the phases of 
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execution to primitive commands or stages of execution for the underlying API, and FIG. 4, 
which shows the tree after such mapping); 

(d) creating a block execution order list corresponding to the stage of execution (see, for 
example, step 212 in FIG. 2 and column 5, lines 46-61, which shows creating a sequence or an 
order list of primitive commands for execution); 

(e) submitting the stage of execution to an application real time kernel for management of 
execution of the stage (see, for example, step 214 in FIG. 2 and column 5, lines 54-56, which 
shows submitting the sequence for execution). 

With respect to claim 15 (original), Peercy in view of Barbour further discloses the 
limitation wherein said step (a) comprises a negotiation process in which resource requirements 
of each alternative implementation are considered, along with the costs and benefits of variations 
in such resource requirements, thereby allowing selection of an implementation (see, for 
example, Peercy, column 5, lines 46-61, which shows considering the costs of an implementation 
in terms of execution time and resource requirements and selecting an efficient sequence). 

Allowable Subject Matter 

16. Claims 20-23 would be allowable if rewritten or amended to overcome the rejection(s) 
under 35 U.S. C. 112, second paragraph, set forth in this Office action. 

17. The following is a statement of reasons for the indication of allowable subject matter: 

The prior art of record does not expressly disclose executing an application graph, 
wherein the application graph is dynamically modified, and wherein said executing step includes 
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(a) traversing the application graph, (b) executing processing blocks of the application graph, 
wherein executing the processing blocks specifies a necessary feature, (c) selecting a component 
from a dictionary based on the specified necessary feature, (d) selecting an implementation from 
the selected component based on the hardware configuration, and (e) modifying the application 
graph dynamically at runtime by inserting the set of processing blocks of the selected 
implementation into the graph, in such a manner and combination as recited in independent 
claim 20. Dependent claims 21-23 further limit the method of claim 20. 

Conclusion 

18. The prior art made of record and not relied upon is considered pertinent to Applicant's 
disclosure. 

U.S. Pat. No. 6,823,299 to Contreras et al. ("Contreras") discloses an application graph 
(see, for example, FIG. 3) and an engine that traverses the application graph at runtime (see, for 
example, column 5, lines 13-16). The application graph includes nodes or processing blocks 
(see, for example, column 4, lines 27-36) and edges that represent data flow connections (see, for 
example, column 4, lines 37-44). Contreras further discloses a database or dictionary of nodes 
(see, for example, column 4, lines 9-11). Contreras expressly discloses modifying the 
connections among nodes (see, for example, column 5, lines 25-27) and adding nodes to the 
application graph dynamically at runtime (see, for example, column 5, lines 37-39). 

U.S. Pat. No. 6,052,527 to Delcourt et al. teaches a method of generating platform 
independent software application programs. U.S. Pat. No. 5,999,729 to Tabloski, Jr. et al. 
teaches a system and method for developing computer programs for execution on parallel 
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processing systems. U.S. Pat. No. 5,999,728 to Cable teaches a method and apparatus for 
enhancing the portability of an object oriented interface among multiple platforms. 

19. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Michael J. Yigdall whose telephone number is (571) 272-3707. 
The examiner can normally be reached on Monday through Friday from 7:30am to 4:00pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q. Dam can be reached on (571) 272-3695. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private 
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 



Michael J. Yigdall 
Y Examiner 

Art Unit 2192 



mjy 




TUAN DAM ^ n 
SUPERVISORY PATENT EXAMINER 



